People have benefited from the proliferation of online services and resources. Often, the more valuable an online service is, the more likely that the service will need to store sensitive information about subscribers. Securing such information and operations that can access and modify sensitive information is important. Most service providers implement security features for authentication and access control, typically using some form of user or subscriber identity. However, when a person subscribes to many services there may be efficiency and security problems. Credentials such as passwords are often forgotten and take time to reset or replace. People often use the same password for many different service accounts, which creates a security vulnerability.
Authentication brokering has been one solution to this problem of account and credential overload. An authentication broker is a service that enables a person to use one authentication (login) and one corresponding credential to authenticate themselves to any service provider that is configured to interoperate with the authentication broker. The authentication broker and service providers may each be managed as separate security domains (a security domain being a set of computers that authorize access based on a same credential, a computer may be in multiple security domains, and a resource provider may manage its own credentials for its own security domain while also participating in the brokered security domain). Typically, a user presents an identity (e.g., a user name) and one or more authentication factors to the authentication broker. The authentication broker evaluates the factors presented by the user and if they are found to be valid then the authentication broker considers the identity of the user to have been authenticated. Consequently, the authentication broker issues a credential—typically a token—that can be repeatedly used as a form of badge or pass for entry to the secure resource providers without having to manually log in each time.
When the user attempts to access an online resource of a resource provider using an authentication broker's token, the resource provider still has an authentication procedure. However, authentication is primarily based on the token rather than presentation of an authentication factor (e.g., a password) to the resource provider. Specifically, as part of the resource provider's authentication procedure, an agent, device, or client operated by the user presents the token to the resource provider. Then, the resource provider (in the case of self-contained tokens) or the authentication broker evaluates the token and if the token is validated then the resource provider is likely to authenticate the user; the resource provider may have other security measures related to authentication. Token validation is often a necessary but not necessarily sufficient condition for authentication.
A number of protocols and standards have been published for authentication brokering. For example, the OAuth 2.0 Authentication Framework (RFC 6749), the X.509 protocol, the Kerberos protocol, the Web Service Security Token Service (STS), the Security Assertion Markup Language (SAML) 2.0 protocol, among others. Procedures may conform to various Web Service (WS) specifications such as WS-TRUST specification. The nature of brokered authentication involves a natural separation between authentication providers and resource providers having respective security domains. The point of brokered authentication is to conveniently off-load authentication to a single convenient access point. Consequently, these brokered authentication protocols have tended to involve simple and unsophisticated exchanges between service providers and authentication brokers. With respect to authentication per se, authentication brokers generally provide basic answers to resource providers, such as “yes, token T is valid”, “yes, token T is valid and it is expired”, “no, token T is not valid”, scope of a token, a time when a token was issued, etc.
Recently, more sophisticated user/identity authentication procedures have become common. Instead of merely authenticating a user with one or two factors and then granting wide access privileges, many authentication procedures have become more flexible and may take into account contextual factors as well as the nature of the resources that authentication would grant access to. Some circumstances of an authentication request may be associated with a heightened security concern. Deviation from patterns of prior authentications may also be considered. Generally, a rich set of information may inform an authentication decision by a resource provider or an authentication broker. However, there has been no appreciation that it could be beneficial to share this type of information among participants in an authentication brokering system. Only the inventors have recognized that it is possible to securely and beneficially share information used to make authentication decisions and evaluate authentication risks.